home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / Documents / CERT / CA-88:01.ftpd.hole < prev    next >
Text File  |  1996-02-15  |  4KB  |  99 lines
  1.  
  2. CA-88:01
  3.                                  CERT Advisory
  4.                      December 1988    
  5.                               ftpd vulnerability
  6. -----------------------------------------------------------------------------
  7.  
  8. There have been several problems or attacks which have occurred in the
  9. past few weeks.  In order to help secure your systems we have gathered
  10. the following suggestions:
  11.  
  12.         1) Check that you are using version 5.59 of sendmail with the
  13.        debug option DISABLED.  To verify the version try the following
  14.        commands.  Use the telnet program to connect to your mail server.
  15.        Telnet to your hostname or localhost with 25 following the host.
  16.            The sendmail program will print a banner which will have the
  17.            version number in it.  You need to be running version 5.59.
  18.            Version 5.61 will be released on Monday 12/12/1988.  Any
  19.            version less than 5.59 is a security problem.
  20.  
  21.            The following is a sample of the telnet command.
  22.  
  23. % telnet localhost 25
  24. Trying...
  25. Connected to localhost.SEI.CMU.EDU.
  26. 220 ed.sei.cmu.edu Sendmail 5.59 ready at Wed, 7 Dec 88 15:45:55 EST
  27. Quit
  28. 221 ed.sei.cmu.edu closing connection
  29. Connection closed by foreign host.
  30. %
  31.  
  32.         2) Verify with your systems support staff that the ftpd program
  33.            patches have been installed.  Removing anonymous ftp is now
  34.            known to NOT plug all security holes.  If you are not sure,
  35.            ftp to ucbarpa.berkeley.edu, login as anonymous password ftp
  36.            and get ftpd.shar.  This file contains the sources to the
  37.            latest BSD release of the ftpd program.
  38.  
  39.         3) Check your /etc/passwd file for bogus entries.  Look for
  40.            unauthorized accounts with the uid field set to zero (only
  41.        the root account should have uid=0).  Remove any unauthorized
  42.            entries.  The following is an example of what you might find.
  43.  
  44.                 install::0:1::/:
  45.  
  46.          To check your /etc/passwd files for spurious accounts with uid 0,
  47.            you can use the following awk program:
  48.  
  49. % awk -F: '$3 == 0 {print $0}' /etc/passwd
  50.  
  51.        If you are running YP on your machine, do:
  52.  
  53. % ypcat passwd | awk [...as above]
  54.  
  55.  
  56.  
  57.         4) Look for modified /bin/login and /usr/ucb/telnet files.
  58.            Several sites have found these programs with new "backdoors"
  59.            added.  Use the strings program to search /bin/login for the
  60.            strings OURPW, knaobj, and knaboj.  If in doubt, reload the
  61.            /bin/login and /usr/ucb/telnet executables from your
  62.            distribution tape.
  63.  
  64. % strings  /bin/login | egrep '(OURPW|knaboj|knaobj)'
  65.  
  66.  
  67.         5) Educate your users to create hard to guess passwords.  Account
  68.            codes, first or last names, and common words are not very
  69.            secure passwords.  A few examples of common words are words
  70.            that refer to your town, location, or company and words that
  71.            are found in /usr/dict/words.  Be especially careful of accounts
  72.            where the password is the account name (easy to check, easy to
  73.            guess.
  74.  
  75.         6) In general, before you allow a user access to the Internet,
  76.        you must be sure you know who they are.  In other words, all
  77.        users should be forced through a login/password sequence
  78.        (no unpassworded accounts and preferably someplace which logs
  79.        connections) before you let them get outside your local network.
  80.        Be especially careful with TCP/IP terminal servers.
  81.  
  82.         7) check the last logs for normal logins as accounts which normally
  83.            run utility programs (sync, who, etc), watch for unreasonable
  84.            times..  watch for ftp's with funny logins (who, etc).
  85. ---------------------------------------------------------------------------
  86.  
  87. Computer Emergency Response Team (CERT)
  88. Software Engineering Institute
  89. Carnegie Mellon University
  90. Pittsburgh, PA 15213-3890
  91.  
  92. Internet: cert@cert.org
  93. Telephone: 412-268-7090 24-hour hotline: CERT personnel answer
  94.            7:30a.m.-6:00p.m. EST, on call for
  95.        emergencies other hours.
  96.  
  97. Past advisories and other information are available for anonymous ftp
  98. from cert.org (192.88.209.5).
  99.